Four ways to skin this cat. (Meeeoooow!)
OK, here is your problem. I think it might be conceptual. My answer is not intended to be insulting if it turns out that I talk beneath you. However, I must gauge my answer based on what I see in your posts.
Lynsey suggested that a form is a window into a table. Actually, this is almost correct. A BOUND form is a window into a particular record source, which could either be a query or a table. Since a query must in turn be bound to one or more tables, a BOUND form is a direct or indirect window into one or more tables. An unbound form is anything you want it to be.
A form is NOT automatically a window into TWO recordsources, but that is what you seem to want. (The two recordsources are tables SFI and SFI Learning, as you described them.) There is an old saying about "one person cannot serve two masters." Well, one form cannot serve two distinct record sources. And that is where you are getting into trouble.
I can think of a few ways to update your SFI Learning table. However, each one requires some design issues to be resolved.
Method 1: Make a join between the two tables that gets all records from SFI and any matching records from SFI Learning. This is a parent/child setup with SFI Learning as the child. It is OK to establish relational integrity for the relationship, in which an entry in SFI Learning MUST correspond to an entry in SFI. Then make the SFI Learning form a sub-form of the parent SFI form. Link the two on whatever is the primary key of the SFI table, assuming you have a primary key. You should then be able to populate the sub-form (at least partially) from the context of the parent, because the controls of the sub-form are visible to the parent form.
Method 2: You can independently activate the form associated with SFI Learning and directly store data in its controls. But you would have to create an appropriate DoCmd action to store THAT form's record. Storing the SFI form shouldn't be difficult because the Access wizards will build you that command button pretty much automatically. Storing another form's record, assuming the form exists and is populated, is just a similar DoCmd action. Other code you might have added in the SFI Form's STORE button is incidental. Look up the DoCmd .Save (or is it .SaveRecord? I always have to look that one up) action as a way to force the other form to store its date. The DoCmd .SaveRecord action normally defaults as to which form's data gets saved, but there is an option that names the form. So a command button on form A can certainly save data on form B.
Method 3: Open a direct recordset to SFI Learning, bypassing the form. Add a new record, populate the fields, and update the recordset. Then close it. I posted some rather detailed instructions recently about how to manipulate recordsets. If you are not familiar with this process and wish to try it, do a search of the forum for recordset info.
Method 4: (This is "iffy.") Make a join between the SFI and SFI learning tables as a peer-to-peer relationship. Relational integrity CANNOT be in force for this join. Don't bother with a separate form for SFI Learning. Instead, when you create the new record for the SFI table, cause some of the other fields that come from the SFI Learning table to also be populated. When you save the form, you save to both records at the same time, because (as long as the relationship is unequivocal) a save through a joined query updates ALL tables that participate in the query. NOTE: This query, to be updatable, cannot contain ANY aggregate functions.